<!DOCTYPE html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
	<title>Configure Elasticsearch for OpenID Connect authentication | ElasticSearch 7.7 权威指南中文版</title>
	<meta name="keywords" content="ElasticSearch 权威指南中文版, elasticsearch 7, es7, 实时数据分析，实时数据检索" />
    <meta name="description" content="ElasticSearch 权威指南中文版, elasticsearch 7, es7, 实时数据分析，实时数据检索" />
    <!-- Give IE8 a fighting chance -->
    <!--[if lt IE 9]>
    <script src="https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js"></script>
    <script src="https://oss.maxcdn.com/respond/1.4.2/respond.min.js"></script>
    <![endif]-->
	<link rel="stylesheet" type="text/css" href="../static/styles.css" />
	<script>
	var _link = 'oidc-guide-authentication.html';
    </script>
</head>
<body>
<div class="main-container">
    <section id="content">
        <div class="content-wrapper">
            <section id="guide" lang="zh_cn">
                <div class="container">
                    <div class="row">
                        <div class="col-xs-12 col-sm-8 col-md-8 guide-section">
                            <div style="color:gray; word-break: break-all; font-size:12px;">原英文版地址: <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.7/oidc-guide-authentication.html" rel="nofollow" target="_blank">https://www.elastic.co/guide/en/elasticsearch/reference/7.7/oidc-guide-authentication.html</a>, 原文档版权归 www.elastic.co 所有<br/>本地英文版地址: <a href="../en/oidc-guide-authentication.html" rel="nofollow" target="_blank">../en/oidc-guide-authentication.html</a></div>
                        <!-- start body -->
                  <div class="page_header">
<strong>重要</strong>: 此版本不会发布额外的bug修复或文档更新。最新信息请参考 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html" rel="nofollow">当前版本文档</a>。
</div>
<div id="content">
<div class="breadcrumbs">
<span class="breadcrumb-link"><a href="index.html">Elasticsearch Guide [7.7]</a></span>
»
<span class="breadcrumb-link"><a href="secure-cluster.html">Secure a cluster</a></span>
»
<span class="breadcrumb-link"><a href="oidc-guide.html">Configuring single sign-on to the Elastic Stack using OpenID Connect</a></span>
»
<span class="breadcrumb-node">Configure Elasticsearch for OpenID Connect authentication</span>
</div>
<div class="navheader">
<span class="prev">
<a href="oidc-guide-op.html">« The OpenID Connect Provider</a>
</span>
<span class="next">
<a href="oidc-role-mapping.html">Configuring role mappings »</a>
</span>
</div>
<div class="section">
<div class="titlepage"><div><div>
<h2 class="title">
<a id="oidc-guide-authentication"></a>Configure Elasticsearch for OpenID Connect authentication<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/x-pack/docs/en/security/authentication/oidc-guide.asciidoc">edit</a>
</h2>
</div></div></div>
<p>The following is a summary of the configuration steps required in order to enable authentication
using OpenID Connect in Elasticsearch:</p>
<div class="olist orderedlist">
<ol class="orderedlist">
<li class="listitem">
<a class="xref" href="oidc-guide-authentication.html#oidc-enable-http" title="Enable TLS for HTTP">Enable SSL/TLS for HTTP</a>
</li>
<li class="listitem">
<a class="xref" href="oidc-guide-authentication.html#oidc-enable-token" title="Enable the token service">Enable the Token Service</a>
</li>
<li class="listitem">
<a class="xref" href="oidc-guide-authentication.html#oidc-create-realm" title="Create an OpenID Connect realm">Create one or more OpenID Connect realms</a>
</li>
<li class="listitem">
<a class="xref" href="oidc-role-mapping.html" title="Configuring role mappings">Configure role mappings</a>
</li>
</ol>
</div>
<div class="section">
<div class="titlepage"><div><div>
<h3 class="title">
<a id="oidc-enable-http"></a>Enable TLS for HTTP<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/x-pack/docs/en/security/authentication/oidc-guide.asciidoc">edit</a>
</h3>
</div></div></div>
<p>If your Elasticsearch cluster is operating in production mode, then you must
configure the HTTP interface to use SSL/TLS before you can enable OpenID Connect
authentication.</p>
<p>For more information, see <a class="xref" href="configuring-tls.html#tls-http" title="Encrypting HTTP client communications">Encrypting HTTP client communications</a>.</p>
</div>

<div class="section">
<div class="titlepage"><div><div>
<h3 class="title">
<a id="oidc-enable-token"></a>Enable the token service<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/x-pack/docs/en/security/authentication/oidc-guide.asciidoc">edit</a>
</h3>
</div></div></div>
<p>The Elasticsearch OpenID Connect implementation makes use of the Elasticsearch Token Service.  This service
is automatically enabled if you configure TLS on the HTTP interface, and can be
explicitly configured by including the following in your <code class="literal">elasticsearch.yml</code> file:</p>
<div class="pre_wrapper lang-yaml">
<pre class="programlisting prettyprint lang-yaml">xpack.security.authc.token.enabled: true</pre>
</div>
</div>

<div class="section">
<div class="titlepage"><div><div>
<h3 class="title">
<a id="oidc-create-realm"></a>Create an OpenID Connect realm<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/x-pack/docs/en/security/authentication/oidc-guide.asciidoc">edit</a>
</h3>
</div></div></div>
<p>OpenID Connect based authentication is enabled by configuring the appropriate realm within
the authentication chain for Elasticsearch.</p>
<p>This realm has a few mandatory settings, and a number of optional settings.
The available settings are described in detail in
<a class="xref" href="security-settings.html#ref-oidc-settings" title="OpenID Connect realm settings">OpenID Connect realm settings</a>. This
guide will explore the most common settings.</p>
<p>Create an OpenID Connect (the realm type is <code class="literal">oidc</code>) realm in your <code class="literal">elasticsearch.yml</code> file
similar to what is shown below:</p>
<div class="note admon">
<div class="icon"></div>
<div class="admon_content">
<p>The values used below are meant to be an example and are not intended to apply to
every use case. The details below the configuration snippet provide insights and suggestions
to help you pick the proper values, depending on your OP configuration.</p>
</div>
</div>
<div class="pre_wrapper lang-yaml">
<pre class="programlisting prettyprint lang-yaml">xpack.security.authc.realms.oidc.oidc1:
  order: 2
  rp.client_id: "the_client_id"
  rp.response_type: code
  rp.redirect_uri: "https://kibana.example.org:5601/api/security/oidc/callback"
  op.issuer: "https://op.example.org"
  op.authorization_endpoint: "https://op.example.org/oauth2/v1/authorize"
  op.token_endpoint: "https://op.example.org/oauth2/v1/token"
  op.jwkset_path: oidc/jwkset.json
  op.userinfo_endpoint: "https://op.example.org/oauth2/v1/userinfo"
  op.endsession_endpoint: "https://op.example.org/oauth2/v1/logout"
  rp.post_logout_redirect_uri: "https://kibana.example.org:5601/logged_out"
  claims.principal: sub
  claims.groups: "http://example.info/claims/groups"</pre>
</div>
<p>The configuration values used in the example above are:</p>
<div class="variablelist">
<dl class="variablelist">
<dt>
<span class="term">
xpack.security.authc.realms.oidc.oidc1
</span>
</dt>
<dd>
This defines a new <code class="literal">oidc</code> authentication realm named "oidc1".
See <a class="xref" href="realms.html" title="Realms">Realms</a> for more explanation of realms.
</dd>
<dt>
<span class="term">
order
</span>
</dt>
<dd>
You should define a unique order on each realm in your authentication chain.
It is recommended that the OpenID Connect realm be at the bottom of your authentication
chain (that is, that it has the <em>highest</em> order).
</dd>
<dt>
<span class="term">
rp.client_id
</span>
</dt>
<dd>
This, usually opaque, arbitrary string, is the Client Identifier that was assigned to the Elastic Stack RP by the OP upon
registration.
</dd>
<dt>
<span class="term">
rp.response_type
</span>
</dt>
<dd>
<p>
This is an identifier that controls which OpenID Connect authentication flow this RP supports and also
which flow this RP requests the OP should follow. Supported values are
</p>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
<code class="literal">code</code>, which means that the RP wants to use the Authorization Code flow. If your OP supports the
Authorization Code flow, you should select this instead of the Implicit Flow.
</li>
<li class="listitem">
<code class="literal">id_token token</code> which means that the RP wants to use the Implicit flow and we also request an oAuth2
access token from the OP, that we can potentially use for follow up requests ( UserInfo ). This
should be selected if the OP offers a UserInfo endpoint in its configuration, or if you know that
the claims you will need to use for role mapping are not available in the ID Token.
</li>
<li class="listitem">
<code class="literal">id_token</code> which means that the RP wants to use the Implicit flow, but is not interested in getting
an oAuth2 token too. Select this if you are certain that all necessary claims will be contained in
the ID Token or if the OP doesn’t offer a User Info endpoint.
</li>
</ul>
</div>
</dd>
<dt>
<span class="term">
rp.redirect_uri
</span>
</dt>
<dd>
The redirect URI where the OP will redirect the browser after authentication. This needs to be
<em>exactly</em> the same as the one <a class="xref" href="oidc-guide-op.html" title="The OpenID Connect Provider">configured with the OP upon registration</a> and will
typically be <code class="literal">${kibana-url}/api/security/oidc/callback</code> where <em>${kibana-url}</em> is the base URL for your Kibana instance
</dd>
<dt>
<span class="term">
op.issuer
</span>
</dt>
<dd>
A verifiable Identifier for your OpenID Connect Provider. An Issuer Identifier is usually a case sensitive URL.
The value for this setting should be provided by your OpenID Connect Provider.
</dd>
<dt>
<span class="term">
op.authorization_endpoint
</span>
</dt>
<dd>
The URL for the Authorization Endpoint in the OP. This is where the user’s browser
will be redirected to start the authentication process. The value for this setting should be provided by your
OpenID Connect Provider.
</dd>
<dt>
<span class="term">
op.token_endpoint
</span>
</dt>
<dd>
The URL for the Token Endpoint in the OpenID Connect Provider. This is the endpoint where
Elasticsearch will send a request to exchange the code for an ID Token.  This setting is optional when
you use the implicit flow. The value for this setting should be provided by your OpenID Connect Provider.
</dd>
<dt>
<span class="term">
op.jwkset_path
</span>
</dt>
<dd>
The path to a file or a URL containing a JSON Web Key Set with the key material that the OpenID Connect
Provider uses for signing tokens and claims responses. If a path is set, it is resolved relative to the Elasticsearch
config directory.
Elasticsearch will automatically monitor this file for changes and will reload the configuration whenever
it is updated. Your OpenID Connect Provider should provide you with this file or a URL where it is available.
</dd>
<dt>
<span class="term">
op.userinfo_endpoint
</span>
</dt>
<dd>
(Optional) The URL for the UserInfo Endpoint in the OpenID Connect Provider. This is the endpoint of the OP that
can be queried to get further user information, if required. The value for this setting should be provided by your
 OpenID Connect Provider.
</dd>
<dt>
<span class="term">
op.endsession_endpoint
</span>
</dt>
<dd>
(Optional) The URL to the End Session Endpoint in the OpenID Connect Provider. This is the endpoint where the user’s
browser will be redirected after local logout, if the realm is configured for RP initiated Single Logout and
the OP supports it. The value for this setting should be provided by your OpenID Connect Provider.
</dd>
<dt>
<span class="term">
rp.post_logout_redirect_uri
</span>
</dt>
<dd>
(Optional) The Redirect URL where the OpenID Connect Provider should redirect the user after a
successful Single Logout (assuming <code class="literal">op.endsession_endpoint</code> above is also set). This should be set to a value that
will not trigger a new OpenID Connect Authentication, such as <code class="literal">${kibana-url}/logged_out</code> where <em>${kibana-url}</em> is
the base URL for your Kibana instance.
</dd>
<dt>
<span class="term">
claims.principal
</span>
</dt>
<dd>
See <a class="xref" href="oidc-guide-authentication.html#oidc-claims-mapping" title="Claims mapping">Claims mapping</a>.
</dd>
<dt>
<span class="term">
claims.groups
</span>
</dt>
<dd>
See <a class="xref" href="oidc-guide-authentication.html#oidc-claims-mapping" title="Claims mapping">Claims mapping</a>.
</dd>
</dl>
</div>
<p>A final piece of configuration of the OpenID Connect realm is to set the <code class="literal">Client Secret</code> that was assigned
to the RP during registration in the OP. This is a secure setting and as such is not defined in the realm
configuration in <code class="literal">elasticsearch.yml</code> but added to the <a class="xref" href="secure-settings.html" title="Secure settings">elasticsearch keystore</a>.
For instance</p>
<div class="pre_wrapper lang-sh">
<pre class="programlisting prettyprint lang-sh">bin/elasticsearch-keystore add xpack.security.authc.realms.oidc.oidc1.rp.client_secret</pre>
</div>
<div class="note admon">
<div class="icon"></div>
<div class="admon_content">
<p>According to the OpenID Connect specification, the OP should also make their configuration
available at a well known URL, which is the concatenation of their <code class="literal">Issuer</code> value with the
<code class="literal">.well-known/openid-configuration</code> string. For example: <code class="literal">https://op.org.com/.well-known/openid-configuration</code>
That document should contain all the necessary information to configure the OpenID Connect realm in Elasticsearch.</p>
</div>
</div>
</div>

<div class="section">
<div class="titlepage"><div><div>
<h3 class="title">
<a id="oidc-claims-mapping"></a>Claims mapping<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/x-pack/docs/en/security/authentication/oidc-guide.asciidoc">edit</a>
</h3>
</div></div></div>
<div class="section">
<div class="titlepage"><div><div>
<h4 class="title">
<a id="_claims_and_scopes"></a>Claims and scopes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/x-pack/docs/en/security/authentication/oidc-guide.asciidoc">edit</a>
</h4>
</div></div></div>
<p>When authenticating to Kibana using OpenID Connect, the OP will provide information about the user
in the form of OpenID Connect Claims, that can be included either in the ID Token, or be retrieved from the
UserInfo endpoint of the OP. The claim is defined as a piece of information asserted by the OP
for the authenticated user. Simply put, a claim is a name/value pair that contains information about
the user. Related to claims, we also have the notion of OpenID Connect Scopes. Scopes are identifiers
that are used to request access to specific lists of claims. The standard defines a set of scope
identifiers that can be requested. The only mandatory one is <code class="literal">openid</code>, while commonly used ones are
<code class="literal">profile</code> and <code class="literal">email</code>. The <code class="literal">profile</code> scope requests access to the <code class="literal">name</code>,<code class="literal">family_name</code>,<code class="literal">given_name</code>,<code class="literal">middle_name</code>,<code class="literal">nickname</code>,
<code class="literal">preferred_username</code>,<code class="literal">profile</code>,<code class="literal">picture</code>,<code class="literal">website</code>,<code class="literal">gender</code>,<code class="literal">birthdate</code>,<code class="literal">zoneinfo</code>,<code class="literal">locale</code>, and <code class="literal">updated_at</code> claims.
The <code class="literal">email</code> scope requests access to the <code class="literal">email</code> and <code class="literal">email_verified</code> claims. The process is that
the RP requests specific scopes during the authentication request. If the OP Privacy Policy
allows it and the authenticating user consents to it, the related claims are returned to the
RP (either in the ID Token or as a UserInfo response).</p>
<p>The list of the supported claims will vary depending on the OP you are using, but you can expect
the <a href="https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims" class="ulink" target="_top">Standard Claims</a> to be
largely supported.</p>
</div>

<div class="section">
<div class="titlepage"><div><div>
<h4 class="title">
<a id="oidc-claim-to-property"></a>Mapping claims to user properties<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/x-pack/docs/en/security/authentication/oidc-guide.asciidoc">edit</a>
</h4>
</div></div></div>
<p>The goal of claims mapping is to configure Elasticsearch in such a way as to be able to map the values of
specified returned claims to one of the <a class="xref" href="oidc-guide-authentication.html#oidc-user-properties" title="Elasticsearch user properties">user properties</a> that are supported
by Elasticsearch. These user properties are then utilized to identify the user in the Kibana UI or the audit
logs, and can also be used to create <a class="xref" href="oidc-role-mapping.html" title="Configuring role mappings">role mapping</a> rules.</p>
<p>The recommended steps for configuring OpenID Claims mapping are as follows:</p>
<div class="olist orderedlist">
<ol class="orderedlist">
<li class="listitem">
Consult your OP configuration to see what claims it might support. Note that
the list provided in the OP’s metadata or in the configuration page of the OP
is a list of potentially supported claims. However, for privacy reasons it might
not be a complete one, or not all supported claims will be available for all
authenticated users.
</li>
<li class="listitem">
Read through the list of <a class="xref" href="oidc-guide-authentication.html#oidc-user-properties" title="Elasticsearch user properties">user properties</a> that Elasticsearch
supports, and decide which of them are useful to you, and can be provided by
your OP in the form of claims. At a <em>minimum</em>, the <code class="literal">principal</code> user property
is required.
</li>
<li class="listitem">
Configure your OP to "release" those claims to your Elastic Stack Relying
party. This process greatly varies by provider. You can use a static
configuration while others will support that the RP requests the scopes that
correspond to the claims to be "released" on authentication time. See
<a class="xref" href="security-settings.html#ref-oidc-settings" title="OpenID Connect realm settings"><code class="literal">rp.requested_scopes</code></a> for details about how
to configure the scopes to request. To ensure interoperability and minimize
the errors, you should only request scopes that the OP supports, and which you
intend to map to Elasticsearch user properties.
</li>
<li class="listitem">
<p>Configure the OpenID Connect realm in Elasticsearch to associate the Elasticsearch user properties (see
<a class="xref" href="oidc-guide-authentication.html#oidc-user-properties" title="Elasticsearch user properties">the listing</a> below), to the name of the claims that your
OP will release. In the example above, we have configured the <code class="literal">principal</code> and
<code class="literal">groups</code> user properties as follows:</p>
<div class="olist orderedlist">
<ol class="orderedlist">
<li class="listitem">
<code class="literal">claims.principal: sub</code> : This instructs Elasticsearch to look for the OpenID Connect claim named <code class="literal">sub</code>
in the ID Token that the OP issued for the user ( or in the UserInfo response ) and assign the
value of this claim to the <code class="literal">principal</code> user property. <code class="literal">sub</code> is a commonly used claim for the
principal property as it is an identifier of the user in the OP and it is also a required
claim of the ID Token, thus offering guarantees that it will be available. It is, however,
only used as an example here, the OP may provide another claim that is a better fit for your needs.
</li>
<li class="listitem">
<code class="literal">claims.groups: "http://example.info/claims/groups"</code> : Similarly, this instructs Elasticsearch to look
for the claim with the name <code class="literal">http://example.info/claims/groups</code> (note that this is a URI - an
identifier, treated as a string and not a URL pointing to a location that will be retrieved)
either in the ID Token or in the UserInfo response, and map the value(s) of it to the user
property <code class="literal">groups</code> in Elasticsearch. There is no standard claim in the specification that is used for
expressing roles or group memberships of the authenticated user in the OP, so the name of the
claim that should be mapped here, will vary greatly between providers. Consult your OP
documentation for more details.
</li>
</ol>
</div>
</li>
</ol>
</div>
</div>

<div class="section">
<div class="titlepage"><div><div>
<h4 class="title">
<a id="oidc-user-properties"></a>Elasticsearch user properties<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/x-pack/docs/en/security/authentication/oidc-guide.asciidoc">edit</a>
</h4>
</div></div></div>
<p>The Elasticsearch OpenID Connect realm can be configured to map OpenID Connect claims to the
following properties on the authenticated user:</p>
<div class="variablelist">
<dl class="variablelist">
<dt>
<span class="term">
principal
</span>
</dt>
<dd>
<em>(Required)</em>
This is the <em>username</em> that will be applied to a user that authenticates
against this realm.
The <code class="literal">principal</code> appears in places such as the Elasticsearch audit logs.
</dd>
</dl>
</div>
<div class="note admon">
<div class="icon"></div>
<div class="admon_content">
<p>If the principal property fails to be mapped from a claim, the authentication fails.</p>
</div>
</div>
<div class="variablelist">
<dl class="variablelist">
<dt>
<span class="term">
groups
</span>
</dt>
<dd>
<em>(Recommended)</em>
If you wish to use your OP’s concept of groups or roles as the basis for a
user’s Elasticsearch privileges, you should map them with this property.
The <code class="literal">groups</code> are passed directly to your <a class="xref" href="oidc-role-mapping.html" title="Configuring role mappings">role mapping rules</a>.
</dd>
<dt>
<span class="term">
name
</span>
</dt>
<dd>
<em>(Optional)</em> The user’s full name.
</dd>
<dt>
<span class="term">
mail
</span>
</dt>
<dd>
<em>(Optional)</em> The user’s email address.
</dd>
<dt>
<span class="term">
dn
</span>
</dt>
<dd>
<em>(Optional)</em> The user’s X.500 <em>Distinguished Name</em>.
</dd>
</dl>
</div>
</div>

<div class="section">
<div class="titlepage"><div><div>
<h4 class="title">
<a id="_extracting_partial_values_from_openid_connect_claims"></a>Extracting partial values from OpenID Connect claims<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/x-pack/docs/en/security/authentication/oidc-guide.asciidoc">edit</a>
</h4>
</div></div></div>
<p>There are some occasions where the value of a claim may contain more information
than you wish to use within Elasticsearch. A common example of this is one where the
OP works exclusively with email addresses, but you would like the user’s
<code class="literal">principal</code> to use the <em>local-name</em> part of the email address.
For example if their email address was <code class="literal">james.wong@staff.example.com</code>, then you
would like their principal to simply be <code class="literal">james.wong</code>.</p>
<p>This can be achieved using the <code class="literal">claim_patterns</code> setting in the Elasticsearch
realm, as demonstrated in the realm configuration below:</p>
<div class="pre_wrapper lang-yaml">
<pre class="programlisting prettyprint lang-yaml">xpack.security.authc.realms.oidc.oidc1:
  order: 2
  rp.client_id: "the_client_id"
  rp.response_type: code
  rp.redirect_uri: "https://kibana.example.org:5601/api/security/oidc/callback"
  op.authorization_endpoint: "https://op.example.org/oauth2/v1/authorize"
  op.token_endpoint: "https://op.example.org/oauth2/v1/token"
  op.userinfo_endpoint: "https://op.example.org/oauth2/v1/userinfo"
  op.endsession_endpoint: "https://op.example.org/oauth2/v1/logout"
  op.issuer: "https://op.example.org"
  op.jwkset_path: oidc/jwkset.json
  claims.principal: email_verified
  claim_patterns.principal: "^([^@]+)@staff\\.example\\.com$"</pre>
</div>
<p>In this case, the user’s <code class="literal">principal</code> is mapped from the <code class="literal">email_verified</code> claim, but a
regular expression is applied to the value before it is assigned to the user.
If the regular expression matches, then the result of the first group is used as the
effective value. If the regular expression does not match then the claim
mapping fails.</p>
<p>In this example, the email address must belong to the <code class="literal">staff.example.com</code> domain,
and then the local-part (anything before the <code class="literal">@</code>) is used as the principal.
Any users who try to login using a different email domain will fail because the
regular expression will not match against their email address, and thus their
principal user property - which is mandatory - will not be populated.</p>
<div class="important admon">
<div class="icon"></div>
<div class="admon_content">
<p>Small mistakes in these regular expressions can have significant
security consequences. For example, if we accidentally left off the trailing
<code class="literal">$</code> from the example above, then we would match any email address where the
domain starts with <code class="literal">staff.example.com</code>, and this would accept an email
address such as <code class="literal">admin@staff.example.com.attacker.net</code>. It is important that
you make sure your regular expressions are as precise as possible so that
you do not inadvertently open an avenue for user impersonation attacks.</p>
</div>
</div>
</div>

</div>

<div class="section">
<div class="titlepage"><div><div>
<h3 class="title">
<a id="third-party-login"></a>Third party initiated single sign-on<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/x-pack/docs/en/security/authentication/oidc-guide.asciidoc">edit</a>
</h3>
</div></div></div>
<p>The Open ID Connect realm in Elasticsearch supports 3rd party initiated login as described in the
<a href="https://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin" class="ulink" target="_top">relevant specification</a>.</p>
<p>This allows the OP itself or another, third party other than the RP, to initiate the authentication
process while requesting the OP to be used for the authentication. Please note that the Elastic
Stack RP should already be configured for this OP, in order for this process to succeed.</p>
</div>

<div class="section">
<div class="titlepage"><div><div>
<h3 class="title">
<a id="oidc-logout"></a>OpenID Connect Logout<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/x-pack/docs/en/security/authentication/oidc-guide.asciidoc">edit</a>
</h3>
</div></div></div>
<p>The OpenID Connect realm in Elasticsearch supports RP-Initiated Logout Functionality as
described in the
<a href="https://openid.net/specs/openid-connect-session-1_0.html#RPLogout" class="ulink" target="_top">relevant part of the specification</a></p>
<p>In this process, the OpenID Connect RP (the Elastic Stack in this case) will redirect the user’s
browser to predefined URL of the OP after successfully completing a local logout. The OP can then
logout the user also, depending on the configuration, and should finally redirect the user back to the
RP. The <code class="literal">op.endsession_endpoint</code> in the realm configuration determines the URL in the OP that the browser
will be redirected to. The <code class="literal">rp.post_logout_redirect_uri</code> setting determines the URL to redirect
the user back to after the OP logs them out.</p>
<p>When configuring <code class="literal">rp.post_logout_redirect_uri</code>, care should be taken to not point this to a URL that
will trigger re-authentication of the user. For instance, when using OpenID Connect to support
single sign-on to Kibana, this could be set to <code class="literal">${kibana-url}/logged_out</code>,  which will show a user-
friendly message to the user.</p>
</div>

<div class="section">
<div class="titlepage"><div><div>
<h3 class="title">
<a id="oidc-ssl-config"></a>OpenID Connect Realm SSL Configuration<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/x-pack/docs/en/security/authentication/oidc-guide.asciidoc">edit</a>
</h3>
</div></div></div>
<p>OpenID Connect depends on TLS to provide security properties such as encryption in transit and endpoint authentication. The RP
is required to establish back-channel communication with the OP in order to exchange the code for an ID Token during the
Authorization code grant flow and in order to get additional user information from the UserInfo endpoint. Furthermore, if
you configure <code class="literal">op.jwks_path</code> as a URL, Elasticsearch will need to get the OP’s signing keys from the file hosted there. As such, it is
important that Elasticsearch can validate and trust the server certificate that the OP uses for TLS. Since the system truststore is
used for the client context of outgoing https connections, if your OP is using a certificate from a trusted CA, no additional
configuration is needed.</p>
<p>However, if the issuer of your OP’s certificate is not trusted by the JVM on which Elasticsearch is running (e.g it uses a organization CA), then you must configure
Elasticsearch to trust that CA. Assuming that you have the CA certificate that has signed the certificate that the OP uses for TLS
stored in the /oidc/company-ca.pem` file stored in the configuration directory of Elasticsearch, you need to set the following
property in the realm configuration:</p>
<div class="pre_wrapper lang-yaml">
<pre class="programlisting prettyprint lang-yaml">xpack.security.authc.realms.oidc.oidc1:
  order: 1
  ...
  ssl.certificate_authorities: ["/oidc/company-ca.pem"]</pre>
</div>
</div>

</div>
<div class="navfooter">
<span class="prev">
<a href="oidc-guide-op.html">« The OpenID Connect Provider</a>
</span>
<span class="next">
<a href="oidc-role-mapping.html">Configuring role mappings »</a>
</span>
</div>
</div>

                  <!-- end body -->
                        </div>
                        <div class="col-xs-12 col-sm-4 col-md-4" id="right_col">
                        
                        </div>
                    </div>
                </div>
            </section>
        </div>
    </section>
</div>
<script src="../static/cn.js"></script>
</body>
</html>